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Abstract 

We present a notion of bounded quantification for refinement types 
and show how it expands the expressiveness of refinement typing 
by using it to develop typed combinators for: (1) relational algebra 
and safe database access, (2) Floyd-Hoare logic within a state trans¬ 
former monad equipped with combinators for branching and loop¬ 
ing, and (3) using the above to implement a refined 10 monad that 
tracks capabilities and resource usage. This leap in expressiveness 
comes via a translation to “ghost” functions, which lets us retain 
the automated and decidable SMT based checking and inference 
that makes refinement typing effective in practice. 

Categories and Subject Descriptors D.2.4 [Software/Program 
Verification]', D.3.3 [Language Constructs and Features]: Poly¬ 
morphism; F.3.1 [Logics and Meanings of Programs]: Specifying 
and Verifying and Reasoning about Programs 

Keywords haskell, refinement types, abstract interpretation 

1. Introduction 

Must program verifiers always choose between expressiveness and 
automation? On the one hand, tools based on higher order logics 
and full dependent types impose no limits on expressiveness, but 
require user-provided (perhaps, tactic-based) proofs. On the other 
hand, tools based on Refinement Types 122. trade expressive¬ 
ness for automation. For example, the refinement types 

type Pos = {v:Int | 0 < v} 

type IntGE x = {v:Int | x < v} 

specify subsets of Int corresponding to values that are positive 
or larger than some other value x respectively. ^ limiting the 
refinement predicates to SMT-decidable logics iT^ . refinement 
type based verifiers eliminate the need for explicit proof terms, and 
thus automate verification. 

This high degree of automation has enabled the use of refine¬ 
ment types for a variety of verification tasks, ranging from array 
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bounds checkin g termination and totality checki ng 12^ . pro¬ 
tocol validation (2,[3l, and securing web applications flCT . Unfor¬ 
tunately, this automation comes at a price. To ensure predictable 
and decidable type checking, we must limit the logical formulas 
appearing in specification types to decidable (typically quantifier 
free) first order theories, thereby precluding higher-order specifi¬ 
cations that are essential for modular verification. 

In this paper, we introduce Bounded Refinement Types which 
reconcile expressive higher order specifications with automatic 
SMT based verification. Our approach comprises two key ingre- 
dients. Our first ingredient is a mechanism, developed by 1^ . for 
abstracting refinements over type signatures. This mechanism is 
the analogue of parametric polymorphism in the refinement setting; 
it increases expressiveness by permitting generic signatures that are 
universally quantified over the (concrete) refinements that hold at 
different call-sites. However, we observe that for modular verifi¬ 
cation, we additionally need to constrain the abstract refinement 
parameters, typically to specify fine grained dependencies between 
the parameters. Our second ingredient provides a technique for en¬ 
riching function signatures with subtyping constraints (or bounds) 
between abstract refinements that must be satisfied by the concrete 
refinements at instantiation. Thus, constrained abstract refinements 
are the analogue of bounded quantification in the refinement setting 
and in this paper, we show that this simple technique proves to be 
remarkably effective. 

• First, we demonstrate via a series of short examples how 
bounded refinements enable the specification and verification 
of diverse textbook higher order abstractions that were hitherto 
beyond the scope of decidable refinement typing (iO. 

• Second, we formalize bounded types and show how bounds are 
translated into “ghost” functions, reducing type checking and 
inference to the “unbounded” setting of 1^ . thereby ensuring 
that checking remains decidable. Furthermore, as the bounds 
are Horn constraints, we can directly reuse the abstract inter¬ 
pretation of Liquid Typing El] to automatically infer concrete 
refinements at instantiation sites (§0. 

• Third, to demonstrate the expressiveness of bounded refine¬ 
ments, we use them to build a typed library for extensible dic¬ 
tionaries, to then implement a relational algebra library on top 
of those dictionaries, and to finally build a library for type-safe 
database access (§0. 

• Finally, we use bounded refinements to develop a Refined State 
Transformer monad for stateful functional programming, based 
upon Filliatre’s method for indexing the monad with pre- and 
post-conditions Si. We use bounds to develop branching and 
looping combinators whose types signatures capture the deriva¬ 
tion rules of Floyd-Hoare logic, thereby obtaining a library for 
writing verified stateful computations (§[5]l. We use this library 
to develop a refined 10 monad that tracks capabilities at a fine- 



granularity, ensuring that functions only access specified re¬ 
sources (§|6j. 

We have implemented Bounded Refinement Types in LlQUID- 
Haskell ll2^ . The source code of the examples (with slightly 
more verbose concrete syntax) is at ll^ . While the construction 
of these verified abstractions is possible with full dependent types, 
bounded refinements keep checking automatic and decidable, use 
abstract interpretation to automatically synthesize refinements (i.e., 
pre- and post-conditions and loop invariants), and most importantly 
enable retroactive or gradual verification as when erase the refine¬ 
ments, we get valid programs in the host language (§ |7). Thus, 
bounded refinements point a way towards keeping our automation, 
and perhaps having expressiveness too. 

2. Overview 

We start with a high level overview of bounded refinement types. To 
make the paper self contained, we begin by recalling the notions of 
abstract refinement types. Next, we introduce bounded refinements, 
and show how they permit modular higher-order specifications. 
Finally, we describe how they are implemented via an elaboration 
process that permits automatic first-order verification. 

2.1 Preliminaries 

Refinement Types let us precisely specify subsets of values, by 
conjoining base types with logical predicates that constrain the 
values. We get decidability of type checking, by limiting these 
predicates to decidable, quantifier-free, first-order logics, including 
the theory of linear arithmetic, uninterpreted functions, arrays, bit- 
vectors and so on. Apart from subsets of values, like the Pos and 
IntGE that we saw in the introduction, we can specify contracts like 
pre- and post-conditions by suitably refining the input and output 
types of functions. 

Preconditions are specified by refining input types. We specify 
that the function assert must only be called with True, where the 
refinement type TRUE contains only the singleton True: 

type TRUE = {v:Bool | v True} 

assert : : TRUE — >■ a ^ a 

assert True x = x 

assert False _ = error "Provably Dead Code" 

We can specify post-conditions by refining output types. For 
example, a primitive Int comparison operator leq can be assigned 
a type that says that the output is True iff the first input is actually 
less than or equal to the second: 

leq :: x:Int y:Int — >■ {v:Bool 1 v x < y} 

Refinement Type Checking proceeds by checking that at each 
application, the types of the actual arguments are subtypes of those 
of the function inputs, in the environment (or context) in which the 
call occurs. Consider the function: 

checkGE :: a:Int — >■ b:IntGE a —>■ Int 

checkGE a b = assert cmp b 
where cmp = a ‘ leq ‘ b 

To verify the call to assert we check that the actual parameter cmp 
is a subtype of TRUE, under the assumptions given by the input types 
for a and b. Via subtyping the check reduces to establishing the 
validity of the verification condition (VC) 


a < b =k (cmp a < b) =k v == cmp =k (v 

true) 

The first antecedent comes from the input type of b, the second 
from the type of cmp obtained from the output of leq, the third 
from the actual input passed to assert, and the goal comes from 
the input type required by assert. An SMT solver ca readily es¬ 
tablishes the validity of the above VC, thereby verifying checkGE. 

First order refinements prevent modular specifications. Con¬ 
sider the function that returns the largest element of a list: 

maximum : : List Int — Int 

maximum [x] = x 

maximum (x:xs) = max x (maximum xs) 
where max a b = if a < b then b else a 

Flow can one write a first-order refinement type specification for 
maximum that will let us verify the below code? 

posMax : : List Pos —>■ Pos 
posMax = maximum 

Any suitable specification would have to enumerate the situations 
under which maximum may be invoked breaking modularity. 

Abstract Refinements overcome the above modularity problems 
m . The main idea is that we can type maximum by observing that it 
returns one of the elements in its input list. Thus, if every element 
of the list enjoys some refinement p then the output value is also 
guaranteed to satisfy p. Concretely, we can type the function as: 

maximum :: V<p:: Int —> Bool >. List Int<p> —> Int<p> 

where informally, Int<p> stands for {v: Int | p v}, and p is an 
uninterpreted function in the refinement logic Ol- The signature 
states that for any refinement p on Int, the input is a list of ele¬ 
ments satisfying p and returns as output an integer satisfying p. In 
the sequel, we will drop the explicit quantification of abstract re¬ 
finements; all free abstract refinements will be implicitly quantified 
at the top-level (as with classical type parameters.) 

Abstract Refinements Preserve Decidability. Abstract refine¬ 
ments do not require the use of higher-order logics. Instead, ab¬ 
stractly refined signatures (like maximum) can be verified by view¬ 
ing the abstract refinements p as uninterpreted functions that only 
satisfy the axioms of congruence, namely: 

Vxy. x = y=>px py 

As the quantifier free theory of uninterpreted functions is decidable 
ca , abstract refinement type checking remains decidable m. 

Abstract Refinements are Automatically Instantiated at call- 
sites, via the abstract interpretation framework of Liquid Typ¬ 
ing (H. Each instantiation yields fresh refinement variables on 
which subtyping constraints are generated; these constraints are 
solved via abstract interpretation yielding the instantiations. Hence, 
we verify posMax by instantiating: 

pi-^Av—>-0<v --at posMax 

2.2 Bounded Refinements 

Even with abstraction, refinement types hit various expressiveness 
walls. Consider the following example from f2S\ . find takes as 
input a predicate q, a continuation k and a starting number i; it 
proceeds to compute the smallest Int (larger than i) that satisfies 
q, and calls k with that value, exi passes find a continuation that 
checks that the “found” value equals or exceeds n. 


exi :: (Int ^ Bool) — >■ Int ^ () 
exl q n = find q (checkGE n) n 

find q k i 

I q i = k i 

I otherwise = find q k (i + 1) 


Function Composition 

First, consider compose. What is a modular specification for 
compose that would let us verify that ex2 enjoys the given spec¬ 
ification? 

compose f g x = f (g x) 


Verification fails as there is no way to specify that k is only called 
with arguments greater than n. First, the variable n is not in scope 
at the function definition and so we cannot refer to it. Second, we 
could try to say that k is invoked with values greater than or equal 
to i, which gets substituted with n at the call-site. Alas, due to the 
currying order, i too is not in scope at the point where k’s type is 
defined and so the type for k cannot depend upon i. 

Can Abstract Refinements Help? Lets try to abstract over the 
refinement that i enjoys, and assign find the type: 

(Int Bool) —>• (Int<p> —>■ a) ^ Int<p> —>• a 


type Plus X y = {v:Int | v = x + y} 
ex2 :: n:Int —> Plus n 2 

ex2 = incr ‘compose' incr 

incr :: n:Int —> Plus n 1 

incr n = n + 1 

The challenge is to chain the dependencies between the input 
and output of g and the input and output of f to obtain a relationship 
between the input and output of the composition. We can capture 
the notion of chaining in a bound: 


which states that for any refinement p, the function takes an input 
i which satisfies p and hence that the continuation is also only 
invoked on a value which trivially enjoys p, namely i. At the call- 
site in exl we can instantiate 

p M> Av —f n < v (1) 

This instantiated refinement is satisfied by the parameter n, and 
sufficient to verify, via function subtyping, that checkGE n will 
only be called with values satisfying p, and hence larger than n. 

find is ill-typed as the signature requires that at the recursive call 
site, the value i+1 also satisfies the abstract refinement p. While 
this holds for the example we have in mind Q, it does not hold/or 
all p, as required by the type of find ! Concretely, {v: Int | v=i+l} 
is in general not a subtype of Int<p>, as the associated VC 

... => p i p (i+1) (2) 


bound Chain pqr=Axyz^ 
qxy=>pyz=frxz 

which states that for any x, y and z, if (1) x and y are related by q, 
and (2) y and z are related by p, then (3) x and z are related by r. 

We use Chain to type compose using three abstract refinements 
p, q and r, relating the arguments and return values of f and g to 
their composed value. (Here, c<r x> abbreviates {v: c | r x v}.) 

compose :: (Chain p q r) ^ (y:b c<p y>) 

^ (x:a —>■ b<q x>) 

(w:a —>■ c<r w>) 

To verify ex2 we instantiate, at the call to compose, 

p, qi—^Axv—>v = x + l 
ri—>.Axv— >'V = x + 2 


is invalid - the type checker thus (soundly!) rejects find. 

We must Bound the Quantification of p to limit it to refinements 
satisfying some constraint, in this case that p is upward closed. In 
the dependent setting, where refinements may refer to program val¬ 
ues, bounds are naturally expressed as constraints between refine¬ 
ments. We define a bound, UpClosed which states that p is a refine¬ 
ment that is upward closed, i.e., satisfies V x. p x p (x+1), 
and use it to type find as: 

bound UpClosed (p :: Int —>■ Bool) 

= Ax ->■ p X ^ p (x + 1) 

find :: (UpClosed p) (Int Bool) 

—V (Int<p> —^ a) 

—>■ Int<p> —>■ a 


The above instantiation satisfies the bound, as shown by the validity 
of the VC derived from instantiating p, q, and r in Chain: 

y==x + l =j.z==y + l =fz==x + 2 
and hence, we can check that ex2 implements its specified type. 

List Filtering 

Next, consider the list filter function. What type signature for 
filter would let us check positives? 

filter q (x:xs) 

I q X = x : filter q xs 

I otherwise = filter q xs 

filter _ [] = [] 


This time, the checker is able to use the bound to verify the VC a. 
We do so in a way that refinements (and thus VCs) remain quanti¬ 
fier free and hence, SMT decidable (§ 12.41 . 

At the call to find in the body of exl , we perform the instantia¬ 
tion Q which generates the arfrfirionfl/VC (n < x ^n < x+1) 
by plugging in the concrete refinements to the bound constraint. 
The SMT solver easily checks the validity of the VC and hence this 
instantiation, thereby statically verifying exl , i.e., that the assertion 
inside checkGE cannot fail. 


positives :: [Int] ->• [Pos] 

positives = filter isPos 

where isPos x = 0 < x 

Such a signature would have to relate the Bool returned by f with 
the property of the x that it checks for. Typed Racket’s latent predi¬ 
cates 1^ account for this idiom, but are a special construct limited 
to Bool-valued “type” tests, and not arbitrary invariants. Another 
approach is to avoid the so-called “Boolean Blindness” that accom¬ 
panies filter by instead using option types and mapMaybe. 


2.3 Bounds for Higher-Order Functions 

Next, we show how bounds expand the scope of refinement typ¬ 
ing by letting us write precise modular specifications for various 
canonical higher-order functions. 


We overcome blindness using a witness bound: 

bound Witness pw = Axb^>b=fwxb^px 

which says that w witnesses the refinement p. That is, for any 
boolean b such that w x b holds, if b is True then p x also holds. 


filter can be given a type saying that the output values enjoy 
a refinement p as long as the test predicate q returns a boolean 
witnessing p: 

filter :: (Witness p w) => (x:a —t Bool<w x>) 

—>■ List a 
—>■ List a<p> 


To verify positives we infer the following type and instantia¬ 
tions for the abstract refinements p and w at the call to filter: 

isPos :: x:Int ^ {viBool | v 0 < x} 

p I— > Av —>■ 0 < V 

w i->-Axb ^bf^0<x 


List Folding 

Next, consider the list fold-right function. Suppose we wish to 
prove the following type for ex3: 

foldr :: (a ^ b ^ b) b List a b 
foldr op b [] = b 

foldr op b (x:xs) = x ‘op‘ foldr op b xs 

ex3 :: xs:List a -)• {v:Int | v == len xs} 

ex3 = foldr (A_ incr) 0 

where len is a logical or measure function used to represent the 
number of elements of the list in the refinement logic 12^ : 

measure len : : List a —>■ Nat 

len [] =0 

len (x:xs) = 1 + len xs 

We specify induction as a bound. Let (1) inv be an abstract 
refinement relating a list xs and the result b obtained by folding 
over it, and (2) step be an abstract refinement relating the inputs 
X, b and output b ’ passed to and obtained from the accumulator op 
respectively. We state that inv is closed under step as: 

bound Inductive inv step = Ax xs b b’ —>■ 

inv xs b ^ step x b b’ => inv (x:xs) b’ 

We can give foldr a type that says that the function outputs a 
value that is built inductively over the entire input list: 


2.4 Implementation 

To implement bounded refinement typing, we must solve two prob¬ 
lems. Namely, how do we (1) check, and (2) use functions with 
bounded signatures? We solve both problems via a unifying insight 
inspired by the way typeclasses are implemented in Haskell. 

1. A Bound Specifies a function type whose inputs are uncon¬ 
strained, and whose output is some value that carries the re¬ 
finement corresponding to the bound’s body. 

2. A Bound is Implemented by a ghost function that returns true, 
but is defined in a context where the bound’s constraint holds 
when instantiated to the concrete refinements at the context. 


We elaborate bounds into ghost functions satisfying the bound’s 
type. To check bounded functions, we need to call the ghost func¬ 
tion to materialize the bound constraint at particular values of in¬ 
terest. Dually, to use bounded functions, we need to create ghost 
functions whose outputs are guaranteed to satisfy the bound con¬ 
straint. This elaboration reduces bounded refinement typing to the 
simpler problem of unbounded abstract refinement typing The 
formalization of our elaboration is described in §[3] Next, we illus¬ 
trate the elaboration by explaining how it addresses the problems 
of checking and using bounded signatures like compose. 


We Translate Bounds into Function Types called the bound- 
type where the inputs are unconstrained, and the outputs satisfy 
the bound’s constraint. For example, the bound Chain used to type 
compose in § 12.31 corresponds to a function type, yielding the 
translated type for compose: 


type ChainTy p q r 
= x:a —t y:b ^ z:c 

^ {v:Bool I qxy=fpyz=>rxz} 


compose :: (ChainTy p q r) 


(y:b c<p y>) 
(x:a b<q x>) 
(w: a —t c<r w>) 


To Check Bounded Functions we view the bound constraints as 
extra (ghost) function parameters (cf. type class dictionaries), that 
satisfy the bound-type. Crucially, each expression where a subtyp¬ 
ing constraint would be generated (by plain refinement typing) is 
wrapped with a “call” to the ghost to materialize the constraint at 
values of interest. For example we elaborate compose into: 


foldr :: (Inductive inv step) 

=> (x:a ^ acc: b —>■ b<step x aco) 
—>■ b<inv []> 

—> xs: List a 
—> b<inv xs> 


compose $chain f g x = 
let t1 = g X 
t2 = f t1 

= $chain x tl t2 -- materialize 

in t2 


That is, for any invariant inv that is inductive under step, if the 
initial value b is inv-related to the empty list, then the folded output 
is inv-related to the input list xs. 

We verify ex3 by inferring, at the call to foldr 

inv I— > Axs v —>■ V == len xs 

step 1 -^ Ax b b ’ ^ b’ == b + 1 

The SMT solver validates the VC obtained by plugging the above 
into the bound. Instantiating the signature for foldr yields pre¬ 
cisely the output type desired for ex3. 

Previously, describes a way to type foldr using abstract 
refinements that required the operator op to have one extra ghost ar¬ 
gument. Bounds let us express induction without ghost arguments. 


In the elaborated version $chain is the ghost parameter corre¬ 
sponding to the bound. As is standard 12111 . we perform ANF- 
conversion to name intermediate values, and then wrap the function 
output with a call to the ghost to materialize the bound’s constraint. 
Consequently, the output of compose, namely t2, is checked to be 
a subtype of the specified output type, in an environment strength¬ 
ened with the bound’s constraint instantiated at x, tl and t2. This 
subtyping reduces to a quantifier free VC: 

q x tl 
=> p tl t2 

=> (q x tl => p tl t2 r X t2) 

=> V == t2 => r x V 

whose first two antecedents are due to the types of tl and t2 (via 
the output types of g and f respectively), and the third comes from 


the call to $chain. The output value v has the singleton refinement 
that states it equals to t2, and finally the VC states that the output 
value V must be related to the input x via r. An SMT solver 
validates this decidable VC easily, thereby verifying compose. 

Our elaboration inserts materialization calls/or all variables (of 
the appropriate type) that are in scope at the given point. This could 
introduce upto calls where k is the number of parameters in the 
bound and n the number of variables in scope. In practice (e.g., in 
compose) this number is small (e.g., 1) since we limit ourselves to 
variables of the appropriate types. 

To preserve semantics we ensure that none of these materializa¬ 
tion calls can diverge, by carefully constraining the structure of the 
arguments that instantiate the ghost functional parameters. 

At Uses of Bounded Functions our elaboration uses the bound- 
type to create lambdas with appropriate parameters that just return 
true. For example, ex2 is elaborated to: 

ex2 = compose (A_ _ _ —^ true) incr incr 

This elaboration seems too naive to be true: how do we ensure that 
the function actually satisfies the bound type? 

Happily, that is automatically taken care of by function sub¬ 
typing. Recalling the translated type for compose, the elaborated 
lambda (A_ _ _ —i true) is constrained to be a subtype of 
ChainTy p q r. In particular, given the call site instantiation 

pi— >Ayz—>z==y + 1 
qi—^Axy—>y==x + 1 
ri—^Axz—>z==x + 2 

this subtyping constraint reduces to the quantifier-free VC: 

[r] => true ^ (z == y + 1) => (y == X + 1) 

^ (z == X + 2) (3) 

where T contains assumptions about the various binders in scope. 
The VC[3]is easily proved valid by an SMT solver, thereby verify¬ 
ing the subtyping obligation defined by the bound, and hence, that 
ex2 satisfies the given type. 

3. Formalism 

Next we formalize Bounded Refinement Types by defining a core 
calculus As and showing how it can be reduced to As, the core 
language of Abstract Refinement Types (H. We start by defining 
the syntax (§ EB and semantics (§ 13.2b of As and the syntax of 
As (§ 13.3b . Next, we provide a translation from As to As (§ l3.4b . 
Then, we prove soundness by showing that our translation is se¬ 
mantics preserving (§ 13.5b . Finally, we describe how type inference 
remains decidable in the presence of bounded refinements (§ 13.6b . 

3.1 Syntax of As 

We build our core language on top of As, the language of Abstract 
Refinement Types VI% . Figure [T] summarizes the syntax of As, a 
polymorphic A-calculus extended with abstract refinements. 

The Expressions of As include the usual variables x, primitive 
constants c, A-abstraction Xx'.t.e, application e e, let bindings 
let X: f = e in e, type abstraction Aa.e, and type application e [t], 
(We add let-binders to As from da as they can be reduced to 
A-abstractions in the usual way.) The parameter t in the type ap¬ 
plication is a refinement type, as described shortly. Finally, A p in¬ 
cludes refinement abstraction Att ■. t.e, which introduces a refine¬ 
ment variable n (with its type t), which can appear in refinements 
inside e, and the corresponding refinement application e [</>] that 
substitutes an abstract refinement with the parametric refinement 
(f>, i.e., refinements r closed under lambda abstractions. 


Expressions 

e ; 

= X 1 c 1 Ax:f.e 1 e 
let X : f = e in e 

Aa.e 1 e [f] 

Att : t.e \ e [0] 

Constants 

c : 

= true 
1 0 1 

1 false 1 crash 

1 1 -1 1 ... 

Parametric Refinements 

(j) : 

= r 1 

Ax: b.(f> 

Predicates 

P : 

= c 1 

-ip 1 p = p 1 . 

Atomic Refinements 

a : 

= P 1 

TT X 

Refinements 

r : 

= “ 1 

a Ar 1 a ^ r 

Basic Types 

b : 

= Int 

1 Bool 1 a 

Types 

t : 

= {u : 

1 : 

b 1 r} 

(x : f) —>■ f 1 r} 

Bounded Types 

P : 

= t 


Schemata 

a : 

= P 1 

Va.a 1 Vtt : t.a 


Figure 1. Syntax of As 


Bounded Types p ::= t\ {(^} => p 

Expressions e ::= ... | A{(^}.e | e{(?)} 


Figure 2. Extending Syntax of As to As 

The Primitive Constants of As include true, false, 0, 1, -1 , etc.. 
In addition, we include a special untypable constant crash that 
models “going wrong”. Primitive operations return a crash when 
invoked with inputs outside their domain, e.g., when / is invoked 
with 0 as the divisor, or when an assert is applied to false. 

Atomic Refinements a are either concrete or abstract refine¬ 
ments. A concrete refinement p is a boolean valued expression 
(such as a constant, negation, equality, etc.) drawn from a strict 
subset of the language of expressions which includes only terms 
that (a) neither diverge nor crash, and (b) can be embedded into an 
SMT decidable refinement logic including the quantifier free the¬ 
ory of linear arithmetic and uninterpreted functions 1^ . An ab¬ 
stract refinement vr x is an application of a refinement variable tt 
to a sequence of program variables. A refinement r is either a con¬ 
junction or implication of atomic refinements. To enable inference, 
we only allow implications to appear within bounds <j) (§ 13. 6b . 

The Types of Xp written t include basic types, dependent func¬ 
tions and schemata quantified over type and refinement variables a 
and TT respectively. A basic type is one of Int, Bool, or a type vari¬ 
able a. A refined type t is either a refined basic type {u : b | r}, 
or a dependent function type {v : {x '. t) ^ t \ r} where the pa¬ 
rameter X can appear in the refinements of the output type. (We 
include refinements for functions, as refined type variables can be 
replaced by function types. However, typechecking ensures these 
refinements are trivially true.) In Ap bounded types p are just a 
synonym for types t. Finally, schemata are obtained by quantifying 
bounded types over type and refinement variables. 

3.2 Semantics of Ap 

Figure [3] summarizes the static semantics of Ap as described in 
El. Unlike El that syntactically separates concrete (p) from 
abstract (tt x) refinements, here, for simplicity, we merge both 
concrete and abstract refinements to atomic refinements a. 

A type environment F is a sequence of type bindings x : cr. We 
use environments to define three kinds of judgments: 







Well-Formedness 


r h (7 


r, u : ti h r : Bool 


r h {w : b I r} 


WF-Base 


r, TT : t h (T 

r h Vtt : t.a 


r h r : Bool T \- tx T,x : tx t 
r h {w : (a; : bj;) —>■ i I r} 

r h cr 


WF-FUN 


WF-ABS-tt 


r h Va.cr 


WF-Abs-o 


Subtyping 


(FI ^ [ril ^ Iral) is valid 
r h {w : b I ri} ^ {t) : b | ra} 


^-Base 


Type Checking 


r, TT : t h (Tl ^ CT 2 
r h Vtt : t.ai ^ Vtt : t.a2 


r h e : (72 r h (72 ^ i7i r h (71 


-<-RVar 


r h (71 ^ (72 


r h Va.(7i X Va.(72 


-<-POLY 


r h e : (71 


T-Sub 


r h Ba; : ta; F, X : tj; 1“ 6 : t F h 1 
F h let a; : = Ba; in e : t 


F h (7l ^ CT2 


F I- t2 ^ ti F,a;2 : i2 F Fi[a:2/a;i] ^ 4 

F h {ti : (a;i : bi) ^ b'l | ri} ^ {i; : (a ;2 : ba) bj | true} 


-<-Fun 


F h B : a 


T-Let 


a; ; {w : b I r} £ F 


T-Var-Base 


a; : b £ F 


F h a; : {v ; b I D = a;} 

F h Bi : (a: : ba;) —>■ b F h 62 : ba; 
F h Bi B2 : b[B2/a;] 

F h B : Vtt : t.a F h Aa; : tx.r' : t 
F h B [Aa; : ba;.r'] : a[\x : tx.r' j-n] 


T-Var 


T-App 


T-PInst 


F h a; : b 

F, a; : ba: F B : b F F ba: 
F F Xx-.tx.e : (a; : ba:) —t b 

F,7r:bFe:(7 FFb 


T-Fun 


F F B : bB (c) 
F, Q F B : (7 


F F Att : b.B : Vtt : t.a 


T-PGen 


F F Aa.e : Vq.(7 

FFb: Va-a F F b 
F F B [r] : (7[b/a] 


T-Const 


T-Gen 


T-Inst 


Figure 3. Static Semantics: Well-formedness, Subtyping and Type Checking 


• Well-formedness judgments (F F a) state that a type schema 
a is well-formed under environment F. That is, the judgment 
states that the refinements in a are boolean expressions in the 
environment F. 

• Subtyping Judgments (F F (7i ^ ( 72 ) state that the type schema 
(71 is a subtype of the type schema (72 under environment F. 
That is, the judgment states that when the free variables of ai 
and a2 are bound to values described by F, the values described 
by (71 are a subset of those described by (72. 

• Typing judgments (F F b : ct) state that the expression e has 
the type schema a under environment F. That is, the judgment 
states that when the free variables in e are bound to values de¬ 
scribed by F, the expression e will evaluate to a value described 
by a. 

The Well-formedness rules check that the concrete and abstract 
refinements are indeed Bool-valued expressions in the appropriate 
environment. The key rule is WF-Base, which checks that the 
refinement r is boolean. 

The Subtyping rules stipulate when the set of values described 
by schema ai is subsumed by [i.e., contained within) the values 
described by CT 2 . The rules are standard except for ^-Base, which 
reduces subtyping of basic types to validity of logical implications, 
by translating the refinements r and the environment F into logical 
formulas: 

[r] = r [F] = /\{r[x/v] | (a;, {u : 6 | r}) £ F} 

Recall that we ensure that the refinements r belong to a decidable 
logic so that validity checking can be performed by an off-the-self 
SMT solver. 


Type Checking Rules are standard except for T-PGen and T- 
PlNST, which pertain to abstraction and instantiation of abstract 
refinements. The rule T-PGen is the same as T-FUN: we simply 
check the body e in the environment extended with a binding 
for the refinement variable tt. The rule T-PInst checks that the 
concrete refinement is of the appropriate (unrefined) type r, and 
then replaces all (abstract) applications of tt inside a with the 
appropriate (concrete) refinement r' with the parameters x replaced 
with arguments at that application. In (H we prove the following 
soundness result for Ap which states that well-typed programs 
cannot crash: 

Lemma (Soundness of Ap (H). If%\-e:a then e (Ap crash. 

3.3 Syntax of Ap 

Figure[2]shows how we obtain the syntax for Ap by extending the 
syntax of Ap with bounded types. 

The Types of Ap extend those of Ap with bounded types p, which 
are the types t guarded by bounds tj). 

The Expressions of Ap extend those of Ap with abstraction over 
bounds A{())}.b and application of bounds e{(j>}. Intuitively, if an 
expression e has some type p then A{(fi}.e has the type {(^} => p. 
We include an explicit bound application form e{(f)} to simplify the 
formalization; these applied bounds are automatically synthesized 
from the type of b, and are of the form Aa:: p.true. 

Notation. We write b, hlytx), {v'.b{nx) | r} to abbreviate 
{u : 6 I true}, {v ■.b\ it x u}, {v : b \ r An x v} respectively. We 
say a type or schema is non-refined if all the refinements in it are 





























true. We get the shape of a type t (i.e., the System-F type) by the 
function Shape(f) defined: 

Shape({u : b \ r}) = b 

Shape({u : (x : ti) —>■ t2 | r}) = Shape(fi) —>■ Shape(f2) 

3.4 Translation from As to Ap 

Next, we show how to translate a term from As to one in Ap. 
We assume, without loss of generality that the terms in As are in 
Administrative Normal Form (i.e., all applications are to variables.) 

Bounds Correspond To Functions that explicitly “witness” the 
fact that the bound constraint holds at a given set of “input” values. 
That is we can think of each bound as a universally quantified re¬ 
lationship between various (abstract) refinements; by “calling” the 
function on a set of input values ..., Xn, we get to instantiate 
the constraint for that particular set of values. 

Bound Environments $ are used by our translation to track the 
set of bound-functions (names) that are in scope at each program 
point. These names are distinct from the regular program variables 
that will be stored in Variable Environments F. We give bound 
functions distinct names so that they cannot appear in the regular 
source, only in the places where calls are inserted by our trans¬ 
lation. The translation ignores refinements entirely; both environ¬ 
ments map their names to their non-refined types. 

The Translation is formalized in Figure |4] via a relation F; $ h 
e e!, that translates the expression e in As into e! in Ap. Most 
of the rules in figure |4] recursively translate the sub-expressions. 
Types that appear inside expressions are syntactically restricted to 
not contain bounds, thus types inside expressions do not require 
translation. Here we focus on the three interesting rules: 


Variable Environment 
Bound Environment 
Translation 

Var 


F ::= 0 I F,a::T 

<1? ::= 0 I <^,X'.T 


F; h e e 


F;<f>l-a;-wa; F;il?l-c--^c 

F'= F,a;:Shape(f) 


Con 


Fun 


F; $ h Ax :f.e Ax :f.lnst(F', e') 

F; $ Cx ei: F' = F, X: Shape(f) F'; <1? h e e' 
F; $ h let X: f = 62: in e let X: r = in lnst(F', e') 

F; d? h ei ei F; $ h 62 62 


Let 


F; $ h ei 62 ei 62 


App 


F; d? h e 6 ^ 


tabs ■ 


F; d? h 6 6^ 


F; d? h Aa.e Aa.e' F; d> F e [f] e' [f] 

F; d? h e 


TAPP 


PAbs 


F; dh h Att : t.e Att : t.e' 

F; d> h 61 62 F; d> h 61 62 

F; $ h 61 [ 62 ] 6 i [ 62 ] 
fresh/ F; d>,/:Shape(^</^) h 66 ' 
F;<&h A{</}. 6 -^ A/:#^ 6 ' 

F; d? h 6 e' 


PApp 


cabs 


F; d> h e{(/} e' Const((/) 


CApp 


Figure 4. Translation Rules from Ap to Ap+ie 


1. At bound abstractions A {</}.6 we convert the bound into a 
bound-function parameter of a suitable type, 

2. At variable binding sites i.e., A- or let-bindings, we use the 
bound functions to materialize the bound constraints for all the 
variables in scope after the binding, 

3. At bound applications e{<j)} we provide regular functions that 
witness that the bound constraints hold. 


1. Rule CAbs translates bound abstractions A{(/}.e into a plain 

A-abstraction. In the translated expression \f ■. .e' the bound 

becomes a function named / with type (|(/D defined: 

(|Ax: 6 .</[) = (x : 6 ) (|(/D 

(|r^ A : Bool | r} 

That is, (|(/D is a function type whose final output carries the refine¬ 
ment corresponding to the constraint in </. Note that the translation 
generates a fresh name / for the bound function (ensuring that it 
cannot be used in the regular code) and saves it in the bound envi¬ 
ronment d> to let us materialize the bound constraint when translat¬ 
ing the body e of the abstraction. 

2. Rules Fun and Let materialize bound constraints at variable 
binding sites (A-abstractions and let-bindings respectively.) If we 
view the bounds as universally quantified constraints over the (ab¬ 
stract) refinements, then our translation exhaustively and eagerly 
instantiates the constraints at each point that a new binder is in¬ 
troduced into the variable environment, over all the possible can¬ 
didate sets of variables in scope at that point. The instantiation is 


performed by lnst(F, e) 

lnst(F, 6) A Wrap(6, lnstances(F, <&)) 

Wrap( 6 , { 61 ,..., 6„}) A let = 61 in ... let = 6n in 6 

(where ti are fresh Bool binders) 

lnstances(F, <&) A ^ f x \ f :t 4^ xTZ •<— F 

, F,f-.T hp / x:Bool} 

The function takes the environments F and <&, an expression e and 
a variable x of type t and uses let-bindings to materialize all the 
bound functions in that accept the variable x. Here, F hp 6: r is 
the standard typing derivation judgment for the non-refined System 
F and so we elide it for brevity. 

3. Rule CApp translates bound applications 6{(/} into plain A 
abstractions that witness that the bound constraints hold. That is, as 
within 6, bounds are translated to a bound function (parameter) of 
type d D, we translate into a A-term that, via subtyping must have 
the required type We construct such a function via Const((/) 
that depends only on the shape of the bound, i.e., the non-refined 
types of its parameters (and not the actual constraint itself). 

Const (r) A true 

Const(Ax: &.</) A Ax: b.Const((/) 

This seems odd: it is simply a constant function, how can it possi¬ 
bly serve as a bound? The answer is that subtyping in the translated 
Ap term will verify that in the context in which the above con¬ 
stant function is created, the singleton true will indeed carry the 
refinement corresponding to the bound constraint, making this syn¬ 
thesized constant function a valid realization of the bound function. 















Recall that in the example ex2 of the overview (§ I2.4> the subtyping 
constraint that decides is the constant true is a valid bound reduces 
to the equationthat is a tautology. 

3.5 Soundness 

The Small-Step Operational Semantics of As are defined by 
extending a similar semantics for Ap which is a standard call- 
by-value calculus where abstract refinements are boolean valued 
functions (H. Let ^p denote the transition relation defining the 
operational semantics of Ap and ^p denote the reflexive transitive 
closure of ^p. We thus obtain the transition relation ^b '■ 

{A.{(j)).e){<j)} e e ^B e',if e e' 

Let ^B denote the reflexive transitive closure of 

The Translation is Semantics Preserving in the sense that if a 
source term e of Ap reduces to a constant then the translated variant 
of e' also reduces to the same constant; 

Lemma. //'0; 0 h e e' and e ^p c then e' ^p c. 

The Soundness of Xb follows by combining the above Semantics 
Preservation Lemma with the soundness of Ap. 

To Typecheck a Xb program e we translate it into a Ap program 
e' and then type check e'\ if the latter check is safe, then we are 
guaranteed that the source term e will not crash: 

Theorem (Soundness). 0; 0 h e e' and 0 h e' : cr then 
e f^*B crash. 

3.6 Inference 

A critical feature of bounded refinements is that we can au¬ 
tomatically synthesize instantiations of the abstract refinements 
by: (1) generating templates corresponding to the unknown types 
where fresh variables n denote the unknown refinements that an 
abstract refinement parameter tt is instantiated with, (2) generating 
subtyping constraints over the resulting templates, and (3) solving 
the constraints via abstract interpretation. 

Inference Requires Monotonic Constraints. Abstract interpreta¬ 
tion only works if the constraints are monotonic a. which in this 
case means that the n variables, and correspondingly, the abstract 
refinements tt must only appear in positive positions within refine¬ 
ments {i.e., not under logical negations). The syntax of refinements 
shown in Figure [T] violates this requirement via refinements of the 
form 7TX=>r. 

We restrict implications to bounds i.e., prohibit them from ap¬ 
pearing elsewhere in type specifications. Consequently, the impli¬ 
cations only appear in the output type of the (first order) “ghost” 
functions that bounds are translated to. The resulting subtyping 
constraints only have implications inside super-types, i.e., as: 

r h {v:b I a} A {v.b | ai ■ • - => a„ => Oq} 

By taking into account the semantics of subtyping, we can push the 
antecedents into the environment, i.e., transform the above into an 
equivalent constraint in the form: 

r, {a:i:fei | a'l},..., {a:„:6n | L {v.b \ a'} A {v.b \ a'q} 

where all the abstract refinements variables tt (and hence instance 
variables k) appear positively, ensuring that the constraints are 
monotonic, hence permitting inference via Liquid Typing a. 


Title 

Director 

Year 

Star 

“Birdman” 

“Persepolis” 

“Inarritu” 

“Paronnaud” 

2014 

2007 

8.1 

8.0 


Figure 5. Example Table of Movies 


4. A Refined Relational Database 

Next, we use bounded refinements to develop a library for relational 
algebra, which we use to enable generic, type safe database queries. 
A relational database stores data in tables, that are a collection of 
rows, which in turn are records that represent a unit of data stored 
in the table. The tables’s schema describes the types of the values in 
each row of the table. For example, the table in Figureorganizes 
information about movies, and has the schema: 

Titie: String , Dir:String, Year:Int, Star:Double 

First, we show how to write type safe extensible records that 
represent rows, and use them to implement database tables (§ 14.11 . 
Next, we show how bounds let us specify type safe relational 
operations and how they may be used to write safe database 
queries (§ 14.21 . 

4.1 Rows and Tables 

We represent the rows of a database with dictionaries, which are 
maps from a set of keys to values. In the sequel, each key corre¬ 
sponds to a column, and the mapped value corresponds to a valua¬ 
tion of the column in a particular row. 

A dictionary Diet <r> k v maps a key x of type k to a value of 
type V that satisfies the property r x 

type Range k v = k —t v ^ Bool 

data Diet k v <r :: Range k v> = D { 
dkeys :: [k] 

, dfun :: x:{k | x g elts dkeys} — t v<r x> 

} 

Each dictionary d has a domain dkeys i.e., the list of keys for which 
d is defined and a function dfun that is defined only on elements x 
of the domain dkeys. For each such element x, dfun returns a value 
that satisfies the property r x. 

Propositions about the theory of sets can be decided efficiently 
by modern SMT solvers. Hence we use such propositions within 
refinements 12^ . The measures (logical functions) elts and keys 
specify the set of keys in a list and a dictionary respectively: 

elts : : [a] —>■ Set a 

elts ([]) = 0 

elts (x:xs) = {x} U elts xs 

keys : : Diet k v —> Set k 

keys d = elts (dkeys d) 

Domain and Range of dictionaries. In order to precisely define 
the domain (e.g., columns) and range (e.g., values) of a dictionary 
(e.g., row), we define the following aliases: 

type RD k V <dom :: Dorn k v, rng :: Range k v> 

= {v:Dict <rng> k v | dom v} 

type Dom k v = Diet k v ^ Bool 

We may instantiate dom and rng with predicates that precisely 
describe the values contained with the dictionary. For example. 








RD < Ad —>■ keys d == {"x”} 

, Ak V—>■ 0 < V > String Int 

describes dictionaries with a single field "x" whose value (as deter¬ 
mined by dfun) is stricly greater than 0. We will define schemas by 
appropriately instantiating the abstract refinements dom and rng. 

An empty dictionary has an empty domain and a function that 
will never be called: 

empty :: RD <emptyRD , rFalse> k v 

empty = D [] (Ax —>■ error "calling empty") 

emptyRD = Ad —> keys d == 0 
rFalse = Ak v —> false 

We define singleton maps as dependent pairs x : = y which de¬ 
note the mapping from x to y: 

data P k V <r :: Range k v> 

= (:=) fpk :: k, pv :: v<r pk>} 

Thus, key := val has type P<r> k v only if r key val. 

A dictionary may be extended with a singleton binding (which 
maps the new key to its new value). 

(+=) :: bind: P<r> k v 

—F diet: RD<pTrue , r> k v 
—F RD OddKey (pk bind) diet, r> k v 

(k := v) += (D ks f) 

= D (k:ks) 

(Ai —F if i == k then v else f i) 

addKey = Ak d d’ —F keys d’ == fk} U keys d 
pTrue = A_ ^ true 

Thus, (k := v) += d evaluates to a dictionary d’ that extends d 
with the mapping from k to v. The type of (+=) constrains the 
new binding bind, the old dictionary diet and the returned value 
to have the same range invariant r. The return type states that the 
output dictionary’s domain is that of the domain of diet extended 
by the new key (pk bind). 

To model a row in a table i.e., a schema, we define the unrefined 
(Haskell) type Schema, which is a dictionary mapping Strings, i.e., 
the names of the fields of the row, to elements of some universe 
Univ containing Int, String and Double. (A closed universe is not 
a practical restriction; most databases support a fixed set of types.) 

data Univ = I Int | S String 1 D Double 

type Schema = RD String Univ 

We refine Schema with concrete instantiations for dom and rng, 
in order to recover precise specifications for a particular database. 
For example, MovieSehema is a refined Schema that describes the 
rows of the Movie table in Figure |5] 

type MovieSehema = RD <md, mr> String Univ 
md = Ad —F 

keys d={"year", "star" , "dir" , "title"} 
mr = Ak V —F 

(k = "year" => isl v && 1888 < tol v) 

&& (k = "star" => isD v && 0 < toD v < 10) 

&& (k = "dir" => isS v) 

&& (k = "title" => isS v) 

isl (I _) = True 


isl _ = False 

tol :: fv: Univ | isl v} —F Int 

tol (I n) = n 

The predicate md describes the domain of the movie schema, re¬ 
stricting the keys to exactly "year", "star”, "dir”, and "title”. 
The range predicate mr describes the types of the values in the 
schema: a dictionary of type MovieSehema must map "year” to 
an Int, "star” to a Double, and "dir” and "title” to Strings. 
The range predicate may be used to impose additional constraints 
on the values stored in the dictionary. For instance, mr restricts the 
year to be not only an integer but also greater than 1888. 

We populate the Movie Schema by extending the empty dictio¬ 
nary with the appropriate pairs of fields and values. For example, 
here are the rows from the table in Figurej^ 


moviel , 

movie2 :: MovieSehema 

moviel = 

("title" 

= 

s 

"Persepolis") 

+= 

("dir" 

= 

s 

"Paronnaud") 

+= 

( "star" 

= 

D 

8) 

+= 

("year" 

= 

I 

2007) 

+= 

empty 




movie2 = 

("title" 

= 

S 

"Birdman ") 

+= 

( "star" 

= 

D 

8.1) 

+= 

("dir" 

= 

S 

"Inarritu") 

+= 

("year" 

= 

I 

2014) 

+= 

empty 





Typing moviel (and movie2) as MovieSehema boils down 
to proving: That keys moviel = {"year", "star”, "dir", 
"title"}; and that each key is mapped to an appropriate value 
as determined by mr. For example, declaring moviel ’s year to be 
I 1888 or even misspelling "dir" as "Dir” will cause the moviel 
to become ill-typed. As the (sub)typing relation depends on logical 
implication (unlike in HList based approaches 1121 ) key ordering 
does not affect type-checking; in moviel the star field is added be¬ 
fore the director, while movie2 follows the opposite order. 

Database Tables are collections of rows, i.e., collections of re¬ 
fined dictionaries. We define a type alias RT s (Refined Table) for 
the list of refined dictionaries from the field type String to the 
Universe. 

type RT (s :: { dom :: TDom , rng :: TRange }) 

= [RD <s.dom, s.rng> String Univ] 

type TDom = Dom String Univ 
type TRange = Range String Univ 

For brevity we pack both the domain and the range refinements 
into a record s that describes the schema refinement; i.e., each row 
dictionary has domain s . dom and range s . rng. 

For example, the table from Figure]^ can be represented as a 
type MoviesTable which is an RT refined with the domain and 
range md and mr described earlier (§ 14.It : 

type MoviesTable = RT {dom = md, rng = mr} 

movies :: MoviesTable 
movies = [moviel , movie2] 

4.2 Relational Algebra 

Next, we describe the types of the relational algebra operators 
which can be used to manipulate refined rows and tables. For space 
reasons, we show the types of the basic relational operators; their 
(verified) implementations can be found online fl^ . 




union : : RT s —>• RT s —>■ RT s 

diff :: RT s ->• RT s ->■ RT s 

select :: (RD s —)• Bool) —> RT s —>■ RT s 

project :: ks:[String] —>■ RTSubEqFlds ks s 
—>■ RTEqFlds ks s 

product :: ( Disjoint si s2, Union si s2 s 
, Range si s, Range s2 s) 

RT si ^ RT s2 —> RT s 

union and diff compute the union and difference, respectively 
of the (rows of) two tables. The types of union and diff state that 
the operators work on tables with the same schema s and return a 
table with the same schema. 

select takes a predicate p and a table t and filters the rows of 
t to those which that satisfy p. The type of select ensures that p 
will not reference columns (fields) that are not mapped in t, as the 
predicate p is constrained to require a dictionary with schema s. 

project takes a list of String fields ks and a table t and projects 
exactly the fields ks at each row of t. project’s type states that for 
any schema s, the input table has type RTSubEqFlds ks s i.e., its 
domain should have at least the fields ks and the result table has 
type RTEqFlds ks s, i.e., its domain has exactly the elements ks. 

type RTSubEqFlds ks s 

= RT sfdom = Az —t elts ks C keys z} 

type RTEqFlds ks s 

= RT sfdom = Az —t elts ks == keys z} 

The range of the argument and the result tables is the same and 
equal to s. rng. 

product takes two tables as input and returns their (Cartesian) 
product. It takes two Refined Tables with schemata si and s2 
and returns a Refined Table with schema s. Intuitively, the output 
schema is the “concatenation” of the input schema; we formalize 
this notion using bounds: (1) Disjoint si s2 says the domains of 
si and s2 should be disjoint, (2) Union si s2 s says the domain 
of s is the union of the domains of si and s2, (3) Range si s (resp. 
Range s2 s2) says the range of si should imply the result range 
s; together the two imply the output schema s preserves the type of 
each key in si or s2. 

bound Disjoint si s2 = Ax y ^ 

si . dom X => s2. dom y =t- keys x n keys y == 0 

bound Union si s2 s = Ax y v ^ 
si . dom X => s2. dom y 

=> keys V == keys x U keys y 
s . dom V 

bound Range si s = Ax k v ^ 

si. dom x =k k S keys x => si . rng k v 
s. rng k V 

Thus, bounded refinements enable the precise typing of re¬ 
lational algebra operations. They let us describe precisely when 
union, intersection, selection, projection and products can be com¬ 
puted, and let us determine, at compile time the exact “shape” of 
the resulting tables. 

We can query Databases by writing functions that use the rela¬ 
tional algebra combinators. For example, here is a query that re¬ 
turns the “good” titles - with more than 8 stars - from the movies 
table [] 

’ More example queries can be found online (H 


good_titles = project ["title”] $ select (Ad —t 
toDouble (dfun d $ "star") > 8 
) movies 

Finally, note that our entire library - including records, tables, 
and relational combinators - is built using vanilla Haskell i.e., with¬ 
out any type level computation. All schema reasoning happens at 
the granularity of the logical refinements. That is if the refinements 
are erased from the source, we still have a well-typed Haskell pro¬ 
gram but of course, lose the safety guarantees about operations 
{e.g., “dynamic” key lookup) never failing at run-time. 

5. A Refined lO Monad 

Next, we illustrate the expressiveness of Bounded Refinements 
by showing how they enable the specification and verification of 
stateful computations. We show how to (1) implement a refined 
state transformer (RIO) monad, where the transformer is indexed 
by refinements corresponding to pre- and poxf-conditions on the 
state (§ 15. lb . (2) extend RIO with a set of combinators for imperative 
programming, i.e., whose types precisely encode Floyd-Hoare style 
program logics (§ and (3) use the RIO monad to write safe 
scripts where the type system precisely tracks capabilities and 
statically ensures that functions only access specific resources (§[^. 

5.1 The RIO Monad 

The RIO data type describes stateful computations. Intuitively, a 
value of type RIO a denotes a computation that, when evaluated 
in an input World produces a value of type a (or diverges) and a 
potentially transformed output World. We implement RIO a as an 
abstractly refined type (as described in &) 

type Pre = World — t Bool 

type Post a = World —t a ^ World —t Bool 

data RIO a <p :: Pre , q :: Post a> = RIO { 

runState :: w:World<p> (x:a, World<q w x>) 

1 

That is, RIO a is a function World— F (a , World), where World is 
a primitive type that represents the state of the machine i.e., the 
console, file system, etc. This indexing notion is directly inspired 
by the method of @] (also used in CS). 

Our Post-conditions are Two-State Predicates that relate the 
input- and output- world (as in El). Classical Floyd-Hoare logic, 
in contrast, uses assertions which are single-state predicates. We 
use two-states to smoothly account for specifications for stateful 
procedures. This increased expressiveness makes the types slightly 
more complex than a direct one-state encoding which is, of course 
also possible with bounded refinements. 

An RIO computation is parameterized by two abstract refine¬ 
ments: (1) p : : Pre, which is a predicate over the input world, 
i.e., the input world w satisfies the refinement p w; and (2) q : : 
Post a, which is a predicate relating the output world with the in¬ 
put world and the value returned by the computation, i.e., the output 
world w ’ satisfies the refinement q w x w ’ where x is the value re¬ 
turned by the computation. Next, to use RIO as a monad, we define 
bind and return functions for it, that satisfy the monad laws. 

The return operator yields a pair of the supplied value z and the 
input world unchanged: 

return :: z:a —F RIO <p, ret z> a 
return z = RIO $ Aw —t (z, w) 

ret z = Aw X w ’ —F w ’ == w && X == z 





The type of return states that for any precondition p and any 
supplied value z of type a, the expression return z is an RIO 
computation with precondition p and a post-condition ret z. The 
postcondition states that: (1) the output World is the same as the 
input, and (2) the result equals to the supplied value z. Note that as 
a consequence of the equality of the two worlds and congruence, 
the output world w ’ trivially satisfies p w ’. 

The »= Operator is defined in the usual way. However, to type 
it precisely, we require bounded refinements. 

(»=) :: (Ret q1 r, Seq r ql p2, Trans q1 q2 q) 
m : RIO <p , ql > a 

—r k:(x:a<r> —>■ RIO <p2 x, q2 x> b) 

—^ RIO <p, q> b 

(RIO g) »= f = RIO $ Ax ->■ 

case g x of { (y, s) —>■ runState (f y) s } 

The bounds capture various sequencing requirements (c.f. the 
Floyd-Hoare rules of consequence). First, the output of the first ac¬ 
tion m, satisfies the refinement required by the continuation k; 

bound Ret ql r = Aw x w ’ —>■ ql w x w ’ => r x 

Second, the computations may be sequenced, i.e., the postcondition 
of the first action m implies the precondition of the continuation k 
(which may be dependent upon the supplied value x): 

bound Seq ql p2 = Aw x w’ ^ 
ql wxw’ =>p2xw’ 

Third, the transitive composition of the two computations, implies 
the final postcondition; 

bound Trans ql q2 q = Aw x w’ y w’ ’ —>■ 

ql wxw’ => q2 x w’ y w’’ => q w y w’’ 

Both type signatures would be impossible to use if the program¬ 
mer had to manually instantiate the abstract refinements (i.e., pre- 
and post-conditions.) Fortunately, Liquid Type inference generates 
the instantiations making it practical to use LiquidHaskell to 
verify stateful computations written using do-notation. 

5.2 Floyd-Hoare Logic in the RIO Monad 

Next, we use bounded refinements to derive an encoding of Floyd- 
Hoare logic, by showing how to read and write (mutable) variables 
and typing higher order ifM and whileM combinators. 

We Encode Mutable Variables as fields of the World type. For 
example, we might encode a global counter as a field: 

data World = { ... , ctr :: Int, ... } 

We encode mutable variables in the refinement logic using Mc¬ 
Carthy’s select and update operators for finite maps and the as¬ 
sociated axiom: 

select : : Map k v —>• k —>■ v 

update : : Map k v —>• k —>■ v ^ Map k v 

V m, kl , k2 , V. 

select (update m kl v) k2 
== (if kl == k2 then v else select m k2 v) 

The quantifier free theory of select and update is decidable and 
implemented in modern SMT solvers jl|]. 


We Read and Write Mutable Variables via suitable “get” and 
“set” actions. For example, we can read and write ctr via: 

getCtr :: RIO <pTrue, rdCtr> Int 
getCtr = RIO $ Aw —f (ctr w, w) 

setCtr :: Int RIO <pTrue, wrCtr n> () 
setCtr n = RIO $ Aw —> ((), w { ctr = n }) 

Here, the refinements are defined as: 
pTrue = Aw —>• True 

rdCtr = Aw X w’ —> w’ == w && x == select w ctr 

wrCtr n = Aw _ w ’ —> w ’ == update w ctr n 

Hence, the post-condition of getCtr states that it returns the current 
value of ctr, encoded in the refinement logic with McCarthy’s 
select operator while leaving the world unchanged. The post¬ 
condition of setCtr states that World is updated at the address 
corresponding to ctr, encoded via McCarthy’s update operator. 

The ifM combinator takes as input a cond action that returns a 
Bool and, depending upon the result, executes either the then or 
else actions. We type it as: 

bound Pure g = Aw x v —>(g w x v v == w) 

bound Then g pi = Aw v —>■ (g w True v ^ pi v) 

bound Else g p2 = Aw v —>■ (g w False v ^ p2 v) 

ifM :: (Pure g, Then g pi. Else g p2) 

=?> RIO <p , g> Bool -- cond 

—r RIO <pl , q> a -- then 

—r RIO <p2, q> a -- else 

—> RIO <p , q> a 

The abstract refinements and bounds correspond exactly to the hy¬ 
potheses in the Floyd-Hoare rule for the if statement. The bound 
Pure g states that the cond action may access but does not modify 
the World, i.e., the output is the same as the input World. (In clas¬ 
sical Floyd-Hoare formulations this is done by syntactically sepa¬ 
rating terms into pure expressions and side effecting statements). 
The bound Then g pi and Else g p2 respectively state that the 
preconditions of the then and else actions are established when 
the cond returns True and False respectively. 

We can use ifM to implement a stateful computation that per¬ 
forms a division, after checking the divisor is non-zero. We specify 
that div should not he called with a zero divisor. Then, LlQUID- 
Haskell verifies that div is called safely: 

div :: Int —> {v:Int | v /= 0} —> Int 
ifTest :: RIO Int 

ifTest = ifM nonZero divX (return 10) 

where nonZero = getCtr »= return (/= 0) 

divX = getCtr »= return . (div 42) 

Verification succeeds as the post-condition of nonZero is in¬ 
stantiated to A_ b w —fb -ft- select w ctr /= 0 and the pre¬ 
condition of divX’s is instantiated to Aw ^select w ctr /= 0, 
which suffices to prove that div is only called with non-zero values. 

The whileM combinator formalizes loops as RIO computations: 

whileM :: (OneState q, Inv p g b, Exit p g q) 

RIO <p, g> Bool -- cond 

—> RIO <pTrue, b> () -- body 

—r RIO <p, q> () 

As with ifM, the hypotheses of the Floyd-Hoare derivation rule 
become bounds for the signature. Given a condition with pre¬ 
condition p and post-condition g and body with a true precondi¬ 
tion and post-condition b, the computation whileM cond body has 


pread , pwrite , plookup , pcontents , 

pcreateD , pcreateF , pcreateFP : : Priv — F Bool 

active : : World Set FH 

caps :: World ^ Map FH Priv 

pset p h = Aw ^ p (select (caps w) h) && 
h G active w 


Figure 6. Privilege Specification 

precondition p and post-condition q as long as the bounds (cor¬ 
responding to the Hypotheses in the Floyd-Hoare derivation rule) 
hold. First, p should be a loop invariant; i.e., when the condition 
returns True the post-condition of the body b must imply the p: 

bound Inv p g b = Aw w’ w’ ’ —F 

p w => g w True w’ => b w ’ () w’’ p w’’ 

Second, when the condition returns False the invariant p should 
imply the loop’s post-condition q: 

bound Exit p g q = Aw w’ —F 

p w =► g w False w’ => q w () w’ 

Third, to avoid having to transitively connect the guard and the 
body, we require that the loop post-condition be a one-state predi¬ 
cate, independent of the input world (as in Floyd-Hoare logic): 

bound OneState q = Aw w’ w’’ 

qw () w’’ => qw’ () w’’ 

We can use whileM to implement a loop that repeatedly decre¬ 
ments a counter while it is positive, and to then verify that if it was 
initially non-negative, then at the end the counter is equal to 0. 

whileTest :: RIO <posCtr , zeroCtr> () 
whileTest = whileM gtZeroX deer 

where gtZeroX = getCtr »= return . (> 0) 

posCtr = Aw —F 0 < select w ctr 
zeroCtr = A_ _ w’ —F 0 == select w ctr 

Where the decrement is implemented by deer with type: 
deer :: RIO <pTrue, decCtr> () 

decCtr = Aw _ w’ —F 

w’ == update w ctr ((select ctr w) - 1) 

LiquidHaskell verifies that at the end of whileTest the counter 
is zero (i.e., the post-condition zeroCtr) by instantiating suitable 
(i.e., inductive) refinements for this particular use of whileM. 

6. Capability Safe Scripting via RIO 

Next, we describe how we use the RIO monad to reason about shell 
scripting, inspired by the Shill ca programming language. 

Shill is a scripting language that restricts the privileges with 
which a script may execute by using capabilities and dynamic con¬ 
tract checking flal . Capabilities are run-time values that witness 
the right to use a particular resource (e.g., a file). A capability is 
associated with a set of privileges, each denoting the permission 
to use the capability in a particular way (such as the permission 
to write to a file). A contract for a Shill procedure describes the 
required input capabilities and any output values. The Shill run¬ 
time guarantees that system resources are accessed in the manner 
described by its contract. 


In this section, we turn to the problem of preventing Shill 
runtime failures. (In general, the verification of file system resource 
usage is a rich topic outside the scope of this paper.) That is, 
assuming the Shill runtime and an API as described in 0, 
how can we use Bounded Refinement Types to encode scripting 
privileges and reason about them statically? 

We use RIO types to specify Shill’s API operations thereby 
providing compile-time guarantees about privilege and resource 
usage. To achieve this, we: connect the state (World) of the RIO 
monad with a privilege specification denoting the set of privileges 
that a program may use (§ 16. lb : specify the. file system API in terms 
of this abstraction (§ l6.2b : and use the above to specify and verify 
the particular privileges that a client of the API uses (§ l6.3b . 

6.1 Privilege Specification 

Figure summarizes how we specify privileges inside RIO. We 
use the type FH to denote a file handles, analogous to Shill’s 
capabilities. An abstract type Priv denotes the sets of privileges 
that may be associated with a particular FH. 

To connect Worlds with Privileges we assume a set of uninter¬ 
preted functions of type Priv — F Bool that act as predicates on 
values of type Priv, each denoting a particular privilege. For ex¬ 
ample, given a value p : : Priv, the proposition pread p denotes 
that p includes the “read” privilege. The function caps associates 
each World with a Map FH Priv, a table that associates each FH 
with its privileges. The function active maps each World to the 
Set of allocated FHs. Given x:FH and w: World, pwrite (select 
(caps w)x) denotes that in the state w, the file x may be written. 
This pattern is generalized by the predicate pset pwrite x w. 

6.2 File System API Specification 

A privilege tracking file system API can be partitioned into the priv¬ 
ilege preserving operations and the privilege extending operations. 

To type the privilege preserving operations, we define a predicate 
eqP w w’ that says that the set of privileges and active handles in 
worlds w and w ’ are equivalent. 

eqP = Aw _ w’ —F 

caps w == caps w’ && active w == active w’ 

We can now specify the privilege preserving operations that read 
and write files, and list the contents of a directory, all of which 
require the capabilities to do so in their pre-conditions: 

read :: {- Read the contents of h -} 
h: FH — F RI0<pset pread h, eqp> String 

write :: {- Write to the file h -} 

h: FH — F String — F RI0<pset pwrite h, eqp> () 

contents :: {- List the children of h -} 
h: FH — F RI0<pset pcontents h, eqp> [Path] 

To type the privilege extending operations, we define predicates 
that say that the output world is suitably extended. First, each such 
operation allocates a new handle, which is formalized as: 

alloc w’ w X = 

(x ^ active w) && active w’ == {x} U active w 

which says that the active handles in (the new World) w’ are those 
of (the old World) w extended with the hitherto inactive handle x. 
Typically, after allocating a new handle, a script will want to add 
privileges to the handle that are obtained from existing privileges. 



To create a new file in a directory with handle h we want the 
new file to have the privileges derived from pcreateFP (select 
(caps w)h) {i.e., the create privileges of h). We formalize this by 
defining the post-condition of create as the predicate derivP: 

derivPh =Awxw’—>■ 
alloc w’ w X && 
caps w’ == store (caps w) x 

(pcreateFP (select (caps w)) h) 

create :: {- Create a file -} 

h: FH—>Path— >-RIO<pset pcreateF h, derivP h> FH 

Thus, if h is writable in the old World w (pwrite (pcreateFP 
(select (caps w)h))) and x is derived from h (derivP w’ w x 
h both hold), then we know that x is writable in the new World w’ 
(pwrite (select (caps w’)x)). 

To lookup existing files or create sub-directories, we want to 
directly copy the privileges of the parent handle. We do this by 
using a predicate copyP as the post-condition for the two functions: 

copyP h = Aw X w ’ — )■ 
alloc w’ w X && 
caps w’ == store (caps w) x 

(select (caps w) y) 

lookup :: {- Open a child of h -} 

h: FH—>Path— >-RIO<pset plookup h, copyP h> FH 

createDir :: {- Create a directory -} 

h: FH ^ Path —>RIO<pset pcreateD h, copyP h> FH 

6.3 Client Script Verification 

We now turn to a client script, the program copyRec that copies the 
contents of the directory f to the directory d. 

copyRec recur s d = 
do cs <- contents s 

forM_ cs $ A p —>■ do 
X <- flookup s p 
when (isFile x) $ do 
y <- create d p 
s <- fread x 
write y s 

when (recur && (isDir x)) $ do 
y <- createDir d p 
copyRec recur x y 

copyRec executes by first listing the contents of f, and then opening 
each child path p in f. If the result is a file, it is copied to the 
directory d. Otherwise, copyRec recurses on p, if recur is true. 

In a first attempt to type copyRec we give it the following type: 

copyRec :: Bool — >• s:FH — >■ d:FH — ^ 

RIO<copySpec s d, 

A_ _ w —>■ copySpec s d w> () 

copySpec h d = Aw — > 

pset pcontents h w && pset plookup h w && 

pset pread h w && pset pcreateFile d w && 

pset pwrite d w && pset pcreateF d w && 

pwrite (pcreateFP (select (caps w) d))) 

The above specification gives copyRec a minimal set of privileges. 
Given a source directory handle s and destination handle d, the 
copyRec must at least: (1) list the contents of s (pcontents), 
(2) open children of s (plookup), (3) read from children of s 
(pread), (4) create directories in d (pcreateD), (5) create files 
in d (pcreateF), an (6) write to (created) files in d (pwrite). 


Furthermore, we want to restrict the privileges on newly created 
files to the write privilege, since copyRec does not need to read 
from or otherwise modify these files. 

Even though the above type is sufficient to verify the vari¬ 
ous clients of copySpec it is insufficient to verify copySpec ’s im¬ 
plementation, as the postcondition merely states that copySpec 
s d w holds. Looking at the recursive call in the last line of 
copySpec ’s implementation, the output world w is only known to 
satisfy copySpec x y w (having substituted the formal parameters 
s and d with the actual x and y), with no mention of s or d! Thus, it 
is impossible to satisfy the postcondition of copyRec, as informa¬ 
tion about s and d has been lost. 

Framing is introduced to address the above problem. Intuitively, 
because no privileges are ever revoked, if a privilege for a file 
existed before the recursive call, then it exists after as well. We 
thus introduce a notion of framing - assertions about unmodified 
state that hold before calling copyRec must hold after copyRec 
returns. Solidifying this intuition, we define a predicate i to be 
Stable when assuming that the predicate i holds on w, if i only 
depends on the allocated set of privileges, then i will hold on a 
world w’ so long as the set of priviliges in w’ contains those in 
w. The definition of Stable is derived precisely from the ways in 
which the file system API may modify the current set of privileges: 

bound Stable i = Ax y w w’ —t- 
i w => ( eqP w () w’ || copyP y w x w’ 

I I derivP y w x w’ 

) =F i w’ 

We thus parameterize copyRec by a predicate i, bounded by 
Stable i, which precisely describes the possible world transfor¬ 
mations under which i should be stable: 

copyFrame isd = Aw—^iw&& copySpec s d w 

copyRec :: (Stable i) =► 

Bool ^ s:FH ^ d: FH 
RIO<copyFrame i s d, 

A_ _ w —> copyFrame i s d w> () 

Now, we can verify copyRec ’s body, as at the recursive call that 
appears in the last line of the implementation, i is instantiated with 
Aw —F copySpec s d w. 

7. Related Work 

Higher order Logics and Dependent Type Systems includ¬ 
ing NuPRL ffl, Coq H, Agda fl^ . and even to some extent, 
Haskell ^ 1^, occupy the maximal extreme of the expressive¬ 
ness spectrum. However, in these settings, checking requires ex¬ 
plicit proof terms which can add considerable programmer over¬ 
head. Our goal is to eliminate the programmer overhead of proof 
construction by restricting specifications to decidable, first order 
logics and to see how far we can go without giving up on expres¬ 
siveness. The F* system enables full dependent typing via SMT 
solvers via a higher-order universally quantified logic that permit 
specifications similar to ours (e.g., compose, filter and foldr). 
While this approach is at least as expressive as bounded refine¬ 
ments it has two drawbacks. First, due to the quantifiers, the gener¬ 
ated VCs fall outside the SMT decidable theories. This renders the 
type system undecidable (in theory), forcing a dependency on the 
solver’s unpredictable quantifier instantiation heuristics (in prac¬ 
tice). Second, more importantly, the higher order predicates must 
be explicitly instantiated, placing a heavy annotation burden on the 
programmer. In contrast, bounds permit decidable checking, and 
are automatically instantiated via Liquid Types. 


Our notion of Refinement Types has its roots in the predicate 
subtyping of PVS and indexed types (DML where types 
are constrained by predicates drawn from a logic. To ensure decid¬ 
able checking several refinement type systems including @,[H,[33] 
restrict refinements to decidable, quantifier free logics. While this 
ensures predictable checking and inference {!][[ it severely limits 
the language of specifications, and makes it hard to fashion simple 
higher order abstractions like filter (let alone the more complex 
ones like relational algebras and state transformers.) 

To Reconcile Expressiveness and Decidability CATALYST in 
permits a form of higher order specifications where refinements are 
relations which may themselves be parameterized by other rela¬ 
tions, which allows for example, a way to precisely type filter 
by suitably composing relations. However, to ensure decidable 
checking, CATALYST is limited to relations that can be specified 
as catamorphisms over inductive types, precluding for example, 
theories like arithmetic. More importantly, (like F*), CATALYST 
provides no inference: higher order relations must be explicitly in¬ 
stantiated. Bounded refinements build directly upon abstract refine¬ 
ments na, a form of refinem ent p olymorphism analogous to para¬ 
metric polymorphism. While |27|| adds expressiveness via abstract 
refinements, without bounds we cannot specify any relationships 
between the abstract refinements. The addition of bounds makes it 
possible to specify and verify the examples shown in this paper, 
while preserving decidability and inference. 

Our Relational Algebra Library builds on a long line of work 
on type safe database access. The HaskellDB 11311 showed how 
phantom types could be used to eliminate certain classes of er¬ 
rors. Haskell’s HList library m extends this work with type-level 
computation features to encode heterogeneous lists, which can be 
used to encode database schema, and (unlike HaskellDB) statically 
reject accesses of “missing” fields. The HList implementation is 
non-trivial, requiring new type-classes for new operations (e.g., 
appending lists); 11 ^ shows how a dependently typed language 
greatly simplifies the implementation. Much of this simplicity can 
be recovered in Haskell using the singleton library H. Our goal 
is to show that bounded refinements are expressive enough to per¬ 
mit the construction of rich abstractions like a relational algebra 
and generic combinators for safe database access while using SMT 
solvers to provide decidable checking and inference. Further, un¬ 
like the HList based approaches, refinements they can be used to 
retroactively or gradually verify safety; if we erase the types we 
still get a valid Haskell program operating over homogeneous lists. 

Our Approach for Verifying Stateful Computations using mon¬ 
ads indexed^ pre- and post-conditions is inspired by the method 
of Filliatre Jg], which was later enriched with separation logic in 
Ynot ca. In future work it would be interesting to use separation 
logic based refinements to specify and verify the complex sharing 
and aliasing patterns allowed by Ynot. F* encodes stateful compu¬ 
tations in a special Dijkstra Monad 1^ that replaces the two as¬ 
sertions with a single (weakest-precondition) predicate transformer 
which can be composed across sub-computations to yield a trans¬ 
former for the entire computation. Our RIO approach uses the idea 
of indexed monads but has two concrete advantages. First, we show 
how bounded refinements alone suffice to let us fashion the RIO ab¬ 
straction from scratch. Consequently, second, we automate infer¬ 
ence of pre- and post-conditions and loop invariants as refinement 
instantiation via Liquid Typing. 
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